home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 4266 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.7 KB
  1. Path: ix.netcom.com!netnews
  2. From: miker3@ix.netcom.com (Mike Rubenstein)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Q:order of evaluation
  5. Date: Mon, 29 Jan 1996 12:56:02 GMT
  6. Organization: Netcom
  7. Message-ID: <310cbc99.219827136@nntp.ix.netcom.com>
  8. References: <4dfhlu$a33$1@mhafn.production.compuserve.com> <hamilton-1801962045570001@dialup-147.austin.io.com> <4dpcfo$293@clarknet.clark.net> <hamilton-2401960104020001@dialup-86.austin.io.com> <3108c867.40236096@nntp.ix.netcom.com> <4eb6kq$ksf@gazette.tandem.com> <31098f8f.11689344@nntp.ix.netcom.com> <4ei45v$mci@axl02it.ntc.nokia.com>
  9. NNTP-Posting-Host: ix-dc7-18.ix.netcom.com
  10. X-NETCOM-Date: Mon Jan 29  4:55:24 AM PST 1996
  11. X-Newsreader: Forte Agent .99c/16.141
  12.  
  13. Risto Lankinen <risto.lankinen@ntc.nokia.com> wrote:
  14.  
  15. > Hi!
  16. > 
  17. > miker3@ix.netcom.com (Mike Rubenstein) wrote:
  18. > >yun_yeogirl <yyg> wrote:
  19. > >
  20. > >> Michael M Rubenstein wrote :
  21. > >> 
  22. > >>         [Example:
  23. > >>           i = v[i++];      // the behavior is undefined
  24. > >> 
  25. > >>           i = ++i + 1;     // the behavior is undefined
  26. > >> 
  27. >    [etc...]
  28. > 
  29. > Isn't the mere existence of this discussion an adequate reason for
  30. > reconsidering the standard when it comes to the evaluation order of
  31. > such expressions?  What I mean is, why does the standard *need* to
  32. > specify that something is 'undefined' when they could be 'defined'
  33. > anyway.  This would have the added bonus that no existing programs
  34. > conforming to the standard won't break simply because they were not
  35. > allowed to make assumptions about undefined behaviour, whereas the
  36. > new programs would have the added power of expression without fear
  37. > of the compilers misinterpreting the intent.
  38. > 
  39. > For example, instead of...
  40. > 
  41. > >>           i = ++i + 1;     // the behavior is undefined
  42. > 
  43. > .. one could define in the standard...
  44. > 
  45. > >>           i = ++i + 1;     // operator+() evaluates and executes
  46. > >>                            // its arguments in the order of their
  47. > >>                            // associativity, ie. '++i' first, the
  48. > >>                            // constant expression '1' next, and
  49. > >>                            // the operator+() last.  Finally, the
  50. > >>                            // result is assigned to 'i'.  Thus the
  51. > >>                            // example equals to 'i = i + 2'.
  52. > 
  53. > .. and within one version cycle all compilers will behave same.
  54. > 
  55. > Or, for curiosity's sake, why not?
  56.  
  57. I don't see the fact that some people just don't bother to learn the
  58. language as a reason, in itself, for changing the standard.  Still,
  59. there would be some advantages to specifying order more closely.
  60.  
  61. But, there would also be disadvantages.  Specification of order cuts
  62. down on optimization possibilities.  On register-poor machines, it is
  63. usually advantageous to evaluate the more complicated subexpression
  64. first, but your rule would prohibit this optimization.  The expression
  65.  
  66.     a + (b + (c + (d * e * f * g)))
  67.  
  68. can be evaluated with only one intermediate if the compiler is allowed
  69. to select the order, but would require 4 under your rule.  Requiring
  70. incrementation to take place immediately places still more burden on
  71. the registers.
  72.  
  73. Is there any evidence that those who do not bother to learn the
  74. present rules will bother to learn the new rules for ordering of
  75. expressions?  I think not.  Look at the problems we have with very
  76. simple things.  The subclause on fflush() (ISO 7.9.5.2) is 12 lines of
  77. text.  The first paragraph of the description is
  78.  
  79.     If stream points to an output stream or an update stream in 
  80.     which the most recent operation was not input, the fflush 
  81.     function causes any unwritten data for that stream to be 
  82.     delivered to the host environment to be written to the file; 
  83.     otherwise the behavior is undefined.
  84.  
  85. Yet we still have people suggesting fflush(stdin).
  86.  
  87.  
  88. Michael M Rubenstein
  89.